home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 4319 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  1.8 KB
  1. Path: rain.fr!world-net!usenet
  2. From: Frederic LACHASSE <lachass@worldnet.fr>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: timing question under MSVC++
  5. Date: Mon, 29 Jan 1996 19:14:08 +0000
  6. Organization: World-Net information exchange, Internet provider.
  7. Message-ID: <VA.00000011.0038ecde@fred>
  8. References: <4eeoul$g1e@news.ust.hk>
  9. Reply-To: lachass@worldnet.fr
  10. NNTP-Posting-Host: client44.sct.fr
  11. X-Newsreader: Virtual Access by Ashmount Research Ltd, http://www.ashmount.com
  12.  
  13. > 
  14. > I've tried to use <time.h> to find out how fast my program is. 
  15. Strangly,
  16. > everytime I compile it with exactly the same compiler options and 
  17. then run it
  18. > with the same inputs, the timing result can still be different. The 
  19. difference
  20. > ranges from 1/100 secs to 1/10 secs. I'm confused. My input was come 
  21. from the
  22. > hard disc.
  23. > 
  24.  
  25. Lots of reason, mostly because of disk I/O:
  26.  
  27. - One of the delay in disk I/O is time when its arm goes from the 
  28. current cylinder to the one needed. That can be as long as twice the 
  29. average time (if you must cross all cylinders) to 0 (you just happen to 
  30. be on the right one).
  31.  
  32. - To accelerate disk I/O, Windows uses the SmartDrive utility to keep 
  33. the latest block from disks in cache memory. Typical configuration has 
  34. about 2MB of memory used that way. Reading a block that is already in 
  35. cache memory can be thousands of times faster than getting it from 
  36. disk. So when reading a second time a file (i.e. while re-executing the 
  37. program), it's generally faster, given that the file isn't too big 
  38. (the program executable plus the file can both stay in cache memory).
  39.  
  40. There's other factors that can change timing randomly, but to a lesser 
  41. degree than I/O operations, so they can be ignored in that case.
  42.  
  43.  Frederic LACHASSE (ECP 86)
  44.  CompuServe: 100530,2005
  45.  Internet: lachass@worldnet.fr
  46.  
  47.